1. Technical Field
The present invention relates generally to an improved data processing system and, in particular, to a method, system and computer program product for optimizing performance in a data processing system. Still more particularly, the present invention provides a method, system, and computer program product for a generic symbol referencing mechanism.
2. Description of Related Art
Application development generally starts with consideration of the design model, and then moves to more user interface oriented tasks. Application development frameworks, such as the Eclipse Modeling Framework (EMF), are designed to ease the design and implementation of a structured model. Eclipse Modeling Framework is part of the Model Driven Architecture (MDA). The idea behind Model Driven Architecture is to be able to develop and manage the whole application life cycle by putting the focus on the model. The model itself is described as a meta-model. Then, by using mappings, the model is used to generate software artifacts, which will implement the real system. Eclipse Modeling Framework can be used to build and describe a model for which Java code can be generated and enhanced by higher level Java code. This implemented model can be used as the basis for any Java application development.
However, because Eclipse Modeling Framework is still under development, at the moment Eclipse Modeling Framework implements only a subset of the Model Driven Architecture approach. As such, it does not contain all the mappings needed to make and deploy an application at a wider level, where Extensible Markup Language (XML), Enterprise Application Integration (EAI), Enterprise Java Beans (EJBs), Web Services, and other technologies need to be combined. One challenge faced in using Eclipse Modeling Framework is that no complete solution is present for resolving references to symbols.
A symbol is a representational token for a concept or quantity. In this context, a symbol is a character or set of characters that represent part of a model that is used to generate software artifacts using specific technologies such as Extensible Markup Language, Enterprise Application Integration, Enterprise Java Beans, and Web Services. Resolving a symbol means converting a symbol in a Java application model into executable Java code or Java code that can be enhanced by higher level Java code.
In order to develop application models that can be generated to produce applications that incorporate XML, EAI, EJBs, Web Services, and other technologies, a Model Driven Architecture must be able to resolve references to symbols used by these technologies. A Model Driven Architecture uses mappings from symbols used by these and other technologies to generate Java code that implements these technologies. Any Model Driven Architecture that cannot resolve symbols used by these technologies cannot directly generate the Java code necessary to implement models developed that use these technologies.
With respect to resolving references to symbols, Eclipse Modeling Framework can only resolve two categories of references to symbols, type and element, and only supports one format for type. Type and element are two specific categories of references to symbols that are supported by Eclipse Modeling Framework. Within these categories, each type and element has a specific name, and each specific name is associated with a specific referencable symbol. Each name is a specific identifier for a symbol, and each referencable symbol is a specific definition for the symbol, a definition that can be used to generate of Java code for the symbol. By using a specific name to reference a specific referencable symbol, Eclipse Modeling Framework can generate the Java code necessary to implement a model that uses the supported type or element.
A registry is a database used to store configuration information, and Eclipse Modeling Framework uses a registry named EPackage.Registry to directly resolve types (such as EClassifier), and to indirectly resolve elements (such as EStructuralFeature). Because type resolving is done directly and element resolving is done indirectly, resolving is not done consistently. EPackage.Registry is not generic, and therefore it cannot resolve type or element as other models other than EClassifier or EStructuralFeature, nor can it resolve other symbols. In addition, EPackage.Registry does not support symbol loading on demand, whereby a registry loads a symbol that was not located when referenced.
Furthermore, EPackage.Registry's scoping of symbols is limited to class loaders, such as global and local. The scope of a symbol is the region of a program source within which the symbol represents a certain thing. This region usually extends from the place where it is declared to the end of the smallest enclosing block, such as a begin/end or procedure/function body. An inner block may contain a redeclaration of the same symbol in which case the scope of the outer declaration does not include (is “shadowed” or “occluded” by) the scope of the inner block. As can be seen, EPackage.Registry's limited scoping of symbols is restrictive for any symbol whose scope extends beyond global and local.
Therefore, it would be advantageous to have a method, system, and computer usable code for resolving references to symbols through a generic symbol referencing mechanism.